The heart of a computer security system is the security reference monitor (SRM). The SRM is the piece of a computer security system that decides whether a particular action is allowed or not, using, for example, an access control list (ACL). Traditionally, an SRM makes a decision based on the subject (who is doing the action), the object (what item is being accessed), and the action (what is being done). The ACLs encode the access rules, and the SRM decides whether an action is allowed or not. In some cases, the SRM decides whether a certain action (such as reading or writing a file) is allowed irrespective of the data being transferred (read or written).
More recently, SRMs have started making decisions based on the actual data. Examples include anti-virus scanners which restrict access to objects (typically file and network resources) based on the contents of the data. Data that appears to contain a virus is not allowed to be accessed or transferred. Other contents-based SRMs can be constructed. For example, a system may be created that, as a basic policy, prevents files that contain the string “Company Confidential” from being sent outside the corporate network.
A block diagram of a conventional contents-based access control system is shown in FIG. 1. An SRM 10 receives data and stores a copy of the data in a memory or associated storage device 15, prior to determining whether the data should be transmitted to a recipient 20. Conventional contents-based access control systems store a copy of the data, and then determine if it is acceptable. Thus, a conventional system stores a copy of the data, even if the data is bad (e.g., not allowed to be transferred or used by a recipient).
Some conventional contents-based access control systems do not actually store the data, but forward it to the recipient immediately. However, this is only secure in situations where the recipient is trusted by the SRM not to use the data until the SRM has decided whether the data is allowed to be used or not, and to delete the data when the SRM decides it should not be used. In effect, in this type of implementation the SRM implements the storage device 15 by having the recipient perform the (trusted) storage function. This is functionally equivalent to FIG. 1.
An example conventional system looks at the entire contents before they can make a decision about whether the data should be restricted or not. For example, if the “Company Confidential” string appears anywhere in the file, the entire file is considered to be confidential, and should not be permitted to be sent outside the corporate network. Similarly, if a virus signature appears anywhere in a data transfer, the whole data transfer should be disallowed. Thus, the first part of the file should not be revealed to the recipient if the last part of the file leads to the decision that the transfer should not be allowed.
This property makes it difficult to integrate contents-based SRMs in streaming communications. For example, an email filtering system would have to receive the whole email, store it, present the data to the SRM to let it decide whether it can be passed on or not, and, if allowed, send the email on. The extra storage step adds significant performance cost, and requires sufficient storage for the data. Without a contents-based SRM, the data could be sent onward as it is being received.
One particular example is in a so-called red/green system where a Hypervisor (or Host) creates one or more partitions, each of which runs its own operating system. Different partitions have different trust levels, and a typical setup has at least one low-trust partition called ‘red’, and one high-trust partition called ‘green’. This system supports file transfers between the red and green partitions. The host (which is the central authority) should enforce the security policies, including contents-based security policies. But storing the whole file that is being transferred is expensive, and the host might not have sufficient disk space to store a large file.
A similar problem occurs when contents-based security policies are applied to other communication mediums. Ideally, the security policy is enforced on the data in transit, but conventional contents-based policies require all of the data to be analyzed before the first part of the data is sent to the recipient.
Some security systems apply security policies on data as it is being transferred. If the policy depends on the actual data in the transfer, then the system must store a copy of the data and apply the policy engine to the data before it can decide whether to allow the transfer to occur. It would be desirable to remove the need for storing a copy of the data.